home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / inet / ien / ien-177 < prev    next >
Text File  |  1988-12-01  |  12KB  |  349 lines
  1.  
  2.  
  3.  
  4.  
  5.                                                                J. Postel
  6. IEN 177                                                              ISI
  7.                                                            24 March 1981
  8.  
  9.  
  10.  
  11.            Comments on Action Items from the January Meeting
  12.  
  13.  
  14.  
  15. At the recent Internet Meeting a number of issues were raised as "action
  16. items" [1].  Many of these can be resolved fairly simply.  This note
  17. describes the resolutions I propose.  These topics may be further
  18. discussed at future meetings or via IENs.  Your comments are requested.
  19.  
  20. Action Items from RSRE:
  21.  
  22.    1.  Dynamic timeouts for retransmission in TCP.
  23.  
  24.       Yes. The algorithm described by RSRE at the October 80 meeting
  25.       should be implemented.  It will be included in the next edition of
  26.       the TCP specification.
  27.  
  28.          The current best procedure for retransmission timeout is to
  29.          measure the time elapsed between sending a data octet with a
  30.          particular sequence number and receiving an ack that covers
  31.          that sequence number (thus one does not have to match sends and
  32.          acks one for one).  Using that measured elapsed time as the
  33.          round trip time (RTT), compute a smoothed round trip time SRTT
  34.          as:
  35.          
  36.                         SRTT = ( ALPHA * SRTT ) + ( (1-ALPHA) * RTT )
  37.  
  38.          And based on this, compute the retransmission timeout (RTO) as:
  39.  
  40.                          RTO = min[ BOUND, BETA * SRTT ]
  41.  
  42.          Where BOUND is an upper bound on the time-out (e.g., 30
  43.          seconds), ALPHA is the smoothing factor (e.g., .8 to .9), and
  44.          BETA is a delay variance factor (e.g., 1.3 to 1.5).
  45.  
  46.    2.  Flag bit for copied options in IP fragments.
  47.  
  48.       Yes.  This makes good sense and will be done in the next edition
  49.       of the IP specification.
  50.  
  51.          The option type octet is viewed as having three fields:
  52.  
  53.             1 bit:   copied flag (0=do not copy, 1=copy)
  54.             2 bits:  option class
  55.             5 bits:  option number
  56.  
  57.  
  58. Postel                                                          [Page 1]
  59.  
  60.  
  61.                                                                  IEN 177
  62. Comments on Action Items from the January Meeting
  63.  
  64.  
  65.  
  66.          The options affected are:  security, source routing (loose &
  67.          strict), and stream identifier.
  68.  
  69.    3.  Specification for strict source routing.
  70.  
  71.       Yes.  In the next edition of the IP specification there will be
  72.       two options: Loose Source Routing (LSR) and Strict Source Routing
  73.       (SSR).  LSR will be the source routing currently specified which
  74.       allows arbitrary internet routing between the listed addresses.
  75.       SSR will have the same syntax, but will require that the next
  76.       listed address be the next internet node visited (where "internet
  77.       node" is a gateway or host), and that it be accessed via the net
  78.       in the listed address.
  79.  
  80.    4.  Standard addresses for Echo, Discard, and Character Generator
  81.    servers.
  82.  
  83.       These already exist.  Assigned Numbers [2] lists ports for both
  84.       UDP and TCP servers as follows:
  85.  
  86.          PORT   SERVER
  87.          ----   ------
  88.            7    Echo
  89.            9    Discard
  90.           19    Character Generator
  91.  
  92.    5.  Techniques for preventing Silly Window Syndrome (SWS).
  93.  
  94.       I am not sure we fully understand this yet, but it is clear that
  95.       very small window updates aggravate the situation.  The next
  96.       edition of the TCP specification will include words of caution
  97.       about small window updates.
  98.  
  99.          Perhaps it should say "don't update the window unless the
  100.          additional space exceeds X percent of the total buffer space
  101.          for this connection".  Any suggestions for the value of X?
  102.  
  103.          The sender can also try to stay out of SWS by only sending big
  104.          segments and waiting until the window is large enough to allow
  105.          it.  If the sending user indicates an end of letter then the
  106.          data must be sent even if it is a small segment.
  107.  
  108.          At the same time we don't want to delay the acknowledgment, so
  109.          when a small segment arrives and is accepted, the typical
  110.          response should be to send an acknowledgement without updating
  111.          the window.
  112.  
  113.       It is also thought that the probing of a zero window with an octet
  114.  
  115.  
  116. Postel                                                          [Page 2]
  117.  
  118.  
  119.                                                                  IEN 177
  120. Comments on Action Items from the January Meeting
  121.  
  122.  
  123.  
  124.       of new data may lead to SWS.  Some consideration of probing with
  125.       the most recent octet of old data is in order.  It is not clear
  126.       that this can be done reliably (does it matter?), or that an "old
  127.       data" probe will elicit new window information.
  128.  
  129.    6.  No changes to addressing for a while.
  130.  
  131.       I am not sure we can do this.  There is clearly a need to provide
  132.       for a large number of networks in the future.  Vint's proposal for
  133.       alternate ways of cuttting up the 32-bit internet address may be
  134.       included in the next edition of the IP specification.
  135.  
  136.          high order bits  format
  137.          ---------------  ------
  138.                0           7 bits of net, 24 bits of host
  139.                10         14 bits of net, 16 bits of host
  140.                110        21 bits of net,  8 bits of host
  141.                111        escape to extended addressing mode
  142.  
  143.       A value of zero in the net field means this net.  The extended
  144.       addressing mode is undefined as yet.
  145.  
  146. Action Items from NDRE:
  147.  
  148.    1.  A HDLC port on the SATNET gateway is needed.
  149.  
  150.       A problem for Vint and BBN.
  151.  
  152.    2.  ARPANET availability must be improved.
  153.  
  154.       A problem for Vint and DCA and BBN.
  155.  
  156. Action Items from MIT:
  157.  
  158.    1.  A maximum segment size TCP option is needed.
  159.  
  160.       Yes.  This can be included in the next edition of the TCP
  161.       specification. The syntax will be the same as the existing Buffer
  162.       Size option.
  163.  
  164. Action Items from DCEC:
  165.  
  166.    1.  How do we provide testing facilities to companies that develop
  167.    TCP products?
  168.  
  169.       A problem for Vint and DCA.
  170.  
  171.  
  172.  
  173.  
  174. Postel                                                          [Page 3]
  175.  
  176.  
  177.                                                                  IEN 177
  178. Comments on Action Items from the January Meeting
  179.  
  180.  
  181.  
  182.    2.  How do we control transit traffic?
  183.  
  184.       This is a difficult problem, and I only promised answers to the
  185.       easy ones.  Right now the only information available for an IP
  186.       gateway to base a decsion on is the stuff in the IP header (source
  187.       and destination address, protocol, tos, security).  In the current
  188.       situation, my approach would be to have a gateway that cares about
  189.       restricting transit traffic to have a list of approved sources and
  190.       have it simply discard and datagram from a source not on the list.
  191.  
  192. Action Items from BBN:
  193.  
  194.    1.  Rubber EOL and Buffer Size has implementation impact in TAC.
  195.  
  196.       My understanding of this is that implementation of TCP in the TAC
  197.       is purposely not capable of handling rubber eol.  A survey of some
  198.       implementers indicates that no implementaion sends the buffer size
  199.       option.  This means that rubber eol never occurs.  Vint suggests
  200.       deleting the buffer size option.  This implies that all the rubber
  201.       eol stuff can go away.  I am prepared to delete the buffer size
  202.       option and all references to the rubber properties of eol from the
  203.       next edition of the TCP specification.  What do you say?
  204.  
  205. Questions from SDC:
  206.  
  207.    1.  Who supplies the "protocol" field for the IP header, IP or the
  208.    transport protocol?
  209.  
  210.       This is an implementation specific issue.  In the simplest case
  211.       the IP just dosen't care what the protocol field says so the upper
  212.       level protocol can supply it on each call.  In a more controlled
  213.       operating system environment the IP would fill in the protocol
  214.       field in the individual datagrams sent based on some initial set
  215.       up call from the upper level protocol module which supplied the
  216.       value at that time.
  217.  
  218.    2.  What is the nature of the interaction between IP and GGP?
  219.  
  220.       The nature of the interaction between IP and GGP can only be
  221.       described as friendly.  Actually, at the meeting I discussed a set
  222.       of messages that combine the messages gateways send to hosts and
  223.       messages that hosts send to hosts about problems with datagrams
  224.       [3].  The plan is to establish this as a separate control protocol
  225.       for IP.  The interaction between the control protocol module and
  226.       the IP module would be very intimate -- they would be the same
  227.       module.
  228.  
  229.  
  230.  
  231.  
  232. Postel                                                          [Page 4]
  233.  
  234.  
  235.                                                                  IEN 177
  236. Comments on Action Items from the January Meeting
  237.  
  238.  
  239.  
  240.    3.  Is source routing loose or strict?
  241.  
  242.       Both.  The current IP specification of the source routing option
  243.       is for the loose source routing.  A similar option for strict
  244.       source routing will be documented.
  245.  
  246. Question from BBN:
  247.  
  248.    1.  How does IP interact with the local net, on errors, on flow
  249.    control, etc.?
  250.  
  251.       Since IP is supposed to work with such radically different local
  252.       nets it is not clear there is an answer to this question.
  253.       Whatever information the local net hands back to the IP about
  254.       errors (e.g., non-delivery) should be communicated to the source
  255.       of the datagram.
  256.  
  257. Question from ISI:
  258.  
  259.    1.  What is the size and precision of time stamps used in internet
  260.    measurements?  What is time zero?
  261.  
  262.       One proposal is the number of milliseconds since midnight 1
  263.       January 1980 GMT modulo 2**32, in other words the low order 32
  264.       bits of that value (32 bits of milliseconds is approximately 49.7
  265.       days).  The IP Timestamp Option now simply says it is 32 bits of
  266.       milliseconds, failing to mention what time zero is, or indicating
  267.       in any way who did the stamping.  I propose to change the option
  268.       to include the internet address of the stamper and to specify time
  269.       zero as 1 January 1980.  This will make the option 10 octets long
  270.       and allow at most 4 stamps in a datagram header.  There is also no
  271.       way to indicate what datagrams are to be stamped. Possibly the
  272.       "stamper addresses" should be filled in by the source to indicate
  273.       which internet modules (gateways or hosts) are supposed to fill in
  274.       times.
  275.  
  276. Action Item for ISI:
  277.  
  278.    1.  A NIFTP-MAIL/MTP interface data structure should be defined soon.
  279.  
  280.       Actually, this is a host specific issue of defining the internal
  281.       stored format for queued mail for multiple recipients.  This
  282.       format may be used by both MTP and NIFTP-MAIL as well as a number
  283.       of user interface programs.  ISI is working on it for TOPS20.
  284.  
  285.  
  286.  
  287.  
  288.  
  289.  
  290. Postel                                                          [Page 5]
  291.  
  292.  
  293.                                                                  IEN 177
  294. Comments on Action Items from the January Meeting
  295.  
  296.  
  297.  
  298. Question from ARPA:
  299.  
  300.    1.  There is a open question about mailbox addresses and the problem
  301.    of sending (and answering) mail to (from) mailboxes in other systems
  302.    (e.g., Internet, TELEMAIL, ONTYME).
  303.  
  304.       The quick answer seems to depend on making another systems
  305.       structured address be one field in your own systems structured
  306.       address.  Even so automatic derivation of reply addresses is hard.
  307.       Otherwise this is a tricky problem.
  308.  
  309. References
  310.  
  311.    [1]  Postel, J., "Internet Meeting Notes -- 28-29-30 January 1981",
  312.         IEN 175, USC/Information Sciences Institute, March 1981.
  313.  
  314.    [2]  Postel, J., "Assigned Numbers", RFC 776, USC/Information
  315.         Sciences Institute, January 1981.
  316.  
  317.    [3]  Postel, J., "What Every Host Should Know About GGP",
  318.         USC/Information Sciences Institute, January 1981.
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338.  
  339.  
  340.  
  341.  
  342.  
  343.  
  344.  
  345.  
  346.  
  347.  
  348. Postel                                                          [Page 6]
  349.